This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
Today there is an increased need for faster network convergence of packet switched networks, such as IP and Ethernet networks due to the increased amount of real time traffic that they carry. In order to provide fast failure handling in IP networks different IP Fast Re-Route (IPFRR) techniques have been introduced. Although, the user traffic is redirected to a backup path very fast, the link-state control protocols applied in IP networks do not converge that fast. Therefore, so called micro-loops may appear during a topology transient, which have to be avoided.
Link-state control protocols are recently proposed to be applied in Ethernet networks too; the architecture is being specified in IEEE 802.1aq Shortest Path Bridging (IEEE 802.1aq Virtual Bridged Local Area Networks—Amendment 9: Shortest Path Bridging, Draft D0.4, Feb. 19, 2008). Loop prevention is essential for Ethernet networks as an accidental loop may cause network meltdown due to the multiplication of looped multicast or broadcast frames. As opposed to IP there is no TTL field in the header of Ethernet frames thus the frames multiplied because of a loop cannot die out from the network.
The application of link-state control protocols in Ethernet networks and in IPFRR networks raise the need of an efficient loop prevention mechanism.
Ingress checking, also referred to as Reverse Path Forwarding Check (RPFC), has been proposed to handle loops in SPB. However, ingress checking does not eliminate all possible loops but only decreases the possibility of temporal loops. That is, accidental loops may appear despite of ingress checking is applied as shown by a couple of examples.
There are various proposals for loop prevention in IPFRR However, each of these methods has significant disadvantages. They are either slow or apply tunneling or require an out-of-control plane protocol (e.g. NTP) etc. Therefore, no straightforward solution has been proposed.